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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


By default, presence delivered using the presence event package for 
the Session Initiation Protocol (SIP) is represented in the Presence 
Information Data Format (PIDF). A PIDF document contains a set of 
elements, each representing a different aspect of the presence being 
reported. When any subset of the elements change, even just a single 
element, a new document containing the full set of elements is 
delivered. This memo defines an extension allowing delivery of only 
the presence data that has actually changed. 
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1. Introduction 
A presence event package for Session Initiation Protocol (SIP) [3] 
allows users (‘watchers’) to subscribe to other users’ 
(’presentities’) presence information. The presence information is 
composed of multiple pieces of data that are delivered to the 
watcher. The size of the presence information document can be large 
(i.e., the presence document can contain an arbitrary number of 


elements called presence tuples that convey data). 


As specified in 


REC 2778 [9] and the presence event package for SIP [3], a Presence 


Agen 


notification. 


t 


(PA) 


always delivers in presence notifications all the presence 
data that has been authorized for a certain watcher. 
regardless of what presence data has changed compared to last 

It may not be reasonable to send the complete presence 


This is done 


information over low bandwidth and high latency links when only part 


of the presence information has actually changed. 


This may end up 


degrading the presence service and causing bad perception at the 
watcher side. 


This document defines a partial notification approach where the 
presence server delivers to the watchers only those parts of the 
presence information that have changed compared to the presence 


information sent in the previous notifications. 


amount of data that is transported over the network. 


This mechanism utilizes the presence event package for SIP 
new MIME type for carrying partial Presence Information Data Format 
documents [2]. 
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Conventions 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 
indicate requirement levels for compliant implementations. 


This document makes use of the vocabulary defined in RFC 2778 [9], 
RFC 3265 [6], the presence event package for SIP [3], and the PIDF 
extension for Partial Presence [2]. 


Introduction to the Partial Notification Mechanism 


This chapter briefly introduces the regular functionality of the 
presence service, and gives an overview of the partial notification 
solution. This section is informational in nature. It does not 
contain any normative statements. 


1. Basic Presence Agent Operation 


The presence service normally operates so that a watcher sends a SIP 
SUBSCRIBE request targeted to the presentity. The request is routed 
to the presence agent where the presentity’s presence information is 
stored. The SUBSCRIBE request can include an Accept header field 
that indicates the supported content types. 


The presence agent receives the SUBSCRIBE request and if there is no 
Accept header indicating the supported content types or the Accept 
header contains the default PIDF content type, the PA will generate 
presence notifications using the default PIDF format [5]. The PIDF 
document can contain one or multiple XML elements. The PIDF document 
includes a set of elements defined in RFC 2778 [9], and its 
extensions for representing the presence information. This PIDF 
document will be carried in the body of a NOTIFY request constructed 
as per RFC 3265 [6]. During basic operation, the presence document 
always contains the full state corresponding to the presence status 
of the presentity, as determined by the PA local policy and 
authorization rules. 


.2. Operation with Partial Notification 


The partial notification mechanism allows a watcher to request that, 
whenever possible, notifications contain only presence information 
that has actually changed. A watcher that wants to receive partial 
notifications according to this document, creates a SIP SUBSCRIBE 
request similar to that of a regular presence subscription. However, 
the SIP SUBSCRIBE request contains an Accept header field whose value 
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contains the "application/pidf-diff+xml" tag as well as the 
"application/pidf+xml" tag. 


When the presence agent receives the subscription, it examines the 
Accept header field value and if the "application/pidf-diff+xml" 
value is present, it can decide to use the partial notifications 


mechanism specified in this memo. The presence agent builds NOTIFY 
requests that contain the Content-Type header field set to 
"application/pidf-diff+xml". The first NOTIFY request that contains 


presence information will contain a full presence document. 
Subsequent NOTIFY requests can contain partial presence documents. 
This behavior is described in detail in Section 4. 


4. Client and Server Operations 


Unless otherwise specified in this document, the regular watcher and 
presence agent behavior is applied as defined in the SIP presence 
event package [3]. 


4.1. Content-Type for Partial Notifications 


Entities supporting the partial notification extension described in 
this document MUST support the 'application/pidf-diff+xml"” content 
type specified in the PIDF extension for partial presence [2]. 


4.2. Watcher Generation of SUBSCRIBE Requests 


A SUBSCRIBE request can be used to negotiate the preferred content 
type to be used in the notifications. The Accept header field is 
used for this purpose as specified in RFC 3261 [4]. When a watcher 
wants to allow the presence agent to send partial notifications the 
watcher MUST include an Accept header field in its SUBSCRIBE request. 
The value of the Accept header field MUST contain 'application/ 
pidf-diff+xml’ (in addition to “application/pidf+xml” required by the 
SIP presence event package [3]). The watcher MAY include a "q" 
parameter with each Accept value to indicate the relative preference 
of that value. 


4.3. Presence Agent Processing of SUBSCRIBE Requests 


The presence agent receives subscriptions from watchers and generates 
notifications according to the SIP presence event package [3]. If 
the watcher has indicated the supported content types in the Accept 
header field of the SUBSCRIBE request, the presence agent compares 
the values included in the Accept header field with the supported 
ones, and decides which one to use. If the watcher has indicated 
preferred accept values by means of "q" parameters, the presence 
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agent SHOULD base the decision on those preferences, unless otherwise 
indicated by the presence agent local policy. 


4.4. Presence Agent Generation of Partial Notifications 


Once a subscription is accepted and installed, the PA MUST deliver 
the full state of the presence information in the first partial 
notification that contains a presence document having <pidf-full> 
root element. If the presence agent decides to send notifications 
that include a presence document according to this specification, the 
presence agent MUST build a presence document according to the PIDF 
extension for Partial Presence [2] and MUST set the Content-Type 
header field to the value 'application/pidf-diff+xml'. 


When using the 'application/pidf-diff+xml” MIME type, the PA MUST 
include a "version" attribute; for the first partial notification 
(within a given subscription), the PA MUST initialize version to 
value one (1). This version counter is scoped to the subscription, 
and is incremented by one within each partial notification. The 
version value is only reset when the given subscription is 
terminated. It is not reset when the subscription is refreshed. 


When the PA generates a partial presence document, the PA SHOULD 
include only that presence information that has changed compared to 
the previous notifications. It is up to the PA’s local policy to 
determine what is considered as a Change to the previous state. 


The PA MUST construct the partial presence document according to the 
following logic: 


o The PA MUST construct the presence information according to the 
PIDF extension for Partial Presence [2]. All the information that 
has been added to the presence document is listed inside <add> 
elements. All information that has been removed from the presence 
document is listed inside <remove> elements, and all information 
that has been changed is listed under <replace> elements. 


o The PA MUST include a "version" attribute in the presence 
document. The PA MUST increment the version number by one 
compared to the earlier successfully sent presence document in the 
PIDF extension for Partial Presence [2] format to the watcher 
associated with a certain subscription. 


The PA MUST NOT send a new NOTIFY request that contains a partial 
notification for the same Request-URI until it has received a final 
response from the watcher for the previous one or the previous NOTIFY 
request has timed out. 
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When the PA receives a SUBSCRIBE request (refresh or termination) 
within the associated subscription, it SHOULD send a NOTIFY request 
containing the full presence document. 


If the PA has used other than the ’application/pidf-diff+xml’ content 
type in notifications within the existing subscription, and changes 
to deliver partial notifications, the PA MUST deliver the full state 
of the presence information containing a presence document having 
<pidf-full> root element as the first partial notification. 


4.5. Watcher Processing of NOTIFY Requests 


Watcher processes all NOTIFY requests that contain 'application/ 
pidf+xml’ content type as specified in RFC 3856 [3]. 


When the watcher receives the first notification containing the 
‘application/pidf—-diff+xml’ MIME body the watcher MUST initialize an 
internal version counter, related to this subscription, to the value 
of the "version" included in the presence document. This version 
counter is scoped to the subscription. The watcher MUST also store 
the received full presence document as its local copy. 


When the watcher receives a subsequent ’application/pidf-diff+xml’ 
encoded presence document the watcher MUST compare the received 
"version" attribute with the local version counter. If the watcher 
receives a presence document with the "version" attribute value equal 
or lower than the locally stored version number, it is considered a 
PA failure, and the watcher SHOULD discard the document without 
further processing. Otherwise, the watcher MUST modify its locally 
stored information according to the following logic: 


o If the root element of the presence document is <pidf-full>, the 
watcher must replace its local copy of the presence document with 
the presence document received in the ’application/pidf-diff+xml’ 
body and set the internal version value to the value of the 
"version" attribute included in the presence document. 


o If the root element of the presence document is <pidf-diff> and 
the received version number is incremented by one compared with 
the local version counter, the watcher MUST apply the changes to 
its local copy of the full presence document indicated in the 
received 'application/pidf-diff+xml” document as specified in PIDF 
extension for Partial Presence [2]. The watcher MUST increment 
the local version counter by one. 
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o If the root element of the presence document is <pidf-diff> and 
the received "version" value is higher by more than one compared 
with the locally stored value, the watcher assumes that one or 
more NOTIFYs were lost. The watcher SHOULD either refresh the 
subscription in order to receive a full presence document or 
terminate the subscription. 


If the watcher encounters a processing error while processing the 
received 'application/pidf-diff+xml” encoded presence document, look 
at Section 5.1 of [8]. In this case, the watcher SHOULD renew the 
subscription. The watcher MAY also fall back to normal presence 
operations by not inserting 'application/pidf-diff+xml” in a new 
SUBSCRIBE request. It is hardly reasonable to signal this error to 
the notifier even if the error exists in the notifier process. 


If the PA changes the content type used in notifications within the 
existing subscription, the watcher MUST discard all the previously 
received presence information (except local version counter) from 
that particular presentity and process the new content as specified 
for that content type. The local version counter MUST NOT be 
discarded because if the PA changes back to 'application/ 
pidf-diff+xml’, the MIME type version counter will continue to 
increase from the last version value. 


5. Examples 


The following message flow shows an example applying the partial 
notifications mechanism. 


A watcher sends a SUBSCRIBE request declaring support for the default 
presence format ('application/pidf+xml) and for the partial 
notification format ('application/pidf-diff+xml') in the Accept 
header field value. The watcher uses the "q" parameter to set the 
preference for receiving partial notifications. The PA accepts the 
subscription and, based on the "q" parameter value, selects to send 
partial notifications in NOTIFY requests. The first NOTIFY request 
includes the full state of presence information. The following 
notifications only include information about delta of the presence 
information from the previous NOTIFY requests. 
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Watcher Presence Agent PUA 
| F1 SUBSCRIBE | | 
Sea SO SS A SS Se e A/A Se > 
| F2 200 OK | 
| <-------------------------- | | 
| F3 NOTIFY | | 
|<------------------------—- | | 
| F4 200 OK | | 
| 
| | Update presence | 
| | <---------=------------- | 
| | | 
| F5 NOTIFY | | 
| <-------------------------- | | 

F6 200 OK 
== mel at A a a Hae e oh o ie > 


Message Details 
F1 SUBSCRIBE watcher->example.com server 


SUBSCRIBE sip:resource@example.com SIP/2.0 

Via: SIP/2.0/TCP watcherhost.example.com; 
branch=z9hG4bKnashds7 

To: <sip:resource@example.com> 

From: <sip:watcher@example.com> ;tag=xfg9 

Call-ID: 2010@watcherhost.example.com 

CSeq: 17766 SUBSCRIBE 

Max-Forwards: 70 

Event: presence 

Accept: application/pidf+xml;q=0.3, 
application/pidf-diff+xml;q=1 

Contact: <sip:user@watcherhost.example.com> 

Expires: 3600 

Content-Length: 0 
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The PA accepts the subscription and generates a 200 OK response 
to the SUBSCRIBE request 


F2 200 OK example.com server ->watcher 


SIP/2.0 200 OK 
Via: SIP/2.0/TCP watcherhost.example.com; 
branch=z9hG4bKnashds7 
; received=192.0.2.1 
To: <sip:resource@example.com>;tag=ffd2 
From: <sip:watcher@example.com>;tag=xfg9 
Call-ID: 2010@watcherhost.example.com 
CSeq: 17766 SUBSCRIBE 
Event: presence 
Expires: 3600 
Contact: <sip:server.example.com> 
Content-Length: 0 


The PA, based on the "q" parameter value in the Accept header 
of the SUBSCRIBE request (F1), decides to use partial 
notifications. The PA creates the first NOTIFY request that 
includes the full presence document. 


F3 NOTIFY example.com server -> watcher 


NOTIFY sip:user@watcherhost.example.com SIP/2.0 

Via: SIP/2.0/TCP server.example.com; 
branch=z9hG4bKna998sk 

To: <sip:watcher@example.com>;tag=xfg9 

From: <sip:resource@example.com>;tag=ffd2 

Call-ID: 2010@watcherhost.example.com 

Event: presence 

Subscription-State: active;expires=3599 

Max-Forwards: 70 

CSeq: 8775 NOTIFY 

Contact: <sip:server.example.com> 

Content-Type: application/pidf-diff+xml 

Content-Length: 


<?xml version="1.0" encoding="UTF-8"?> 

<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf" 
xmlns:p="urn:ietf:params:xml:ns:pidf-diff" 
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid" 
xmlns:c="urn:ietf:params:xml:ns:pidf:caps" 
xmlns:cp="urn:ietf:params:xml:ns:pidf:cipid" 
xml1lns:dm="urn:ietf:params:xml:ns:pidf:data-model" 
entity="sip:resource@example.com" 
version="1"> 
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<tuple id="sg89ae"> 

<status> 
<basic>open</basic> 

</status> 

<c:servcaps> 
<c:audio>true</c:audio> 
<c:video>false</c:video> 
<c:message>true</c:message> 

</c:servcaps> 
<r:relationship><r:assistant/></r:relationship> 
<contact priority="0.8">tel:09012345678</contact> 

</tuple> 


<tuple id="cg231ljcr"> 


<status> 
<basic>open</basic> 
</status> 
<contact priority="1.0">im:res@example.com</contact> 
</tuple> 


<tuple id="r1230d"> 

<status> 

<basic>closed</basic> 

</status> 

<cp:homepage>http://example.com/~ res/</cp:homepage> 
<cp:icon>http://example.com/~res/icon.gif</cp:icon> 
<cp:card>http://example.com/~res/card.vcd</cp:card> 
<contact priority="0.9">sip:resource@example.com</contact> 
</tuple> 


<note xml:lang="en">Full state presence document</note> 


<dm:person id="fdkf3"> 
<r:activities> 
<r:on-the-phone/> 
<r:busy/> 
</r:iactivities> 

</dm:person> 
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<dm:device id="u00b40c7"> 
<c:devcaps> 
<c:mobility> 
<c: supported> 
<c:mobile/> 
</c: supported> 
</c:mobility> 
</c:devcaps> 
<dm: deviceID>mac : xxx</dm:devicelD> 
</dm:device> 


</p:pidf-full> 
F4 200 OK watcher -> example.com server 


SIP/2.0 200 OK 
Via: SIP/2.0/TCP server.example.com; 
branch=z 9hG4bKna998sk 
; received=192.0.2.2 
To: <sip:watcher@example.com>;tag=xfg9 
From: <sip:resource@example.com>;tag=ffd2 
Call-ID: 2010@watcherhost.example.com 
CSeq: 8775 NOTIFY 
Content-Length: 0 


At a later time, the presentity’s presence information 
changes. The PA generates a NOTIFY request 
that includes information about the changes. 


F5 NOTIFY example.com server -> watcher 


NOTIFY sip:user@watcherhost.example.com SIP/2.0 

Via: SIP/2.0/TCP server.example.com; 
branch=z9hG4bKna998s1 

To: <sip:watcher@example.com>;tag=xfg9 

From: <sip:resource@example.com>;tag=ffd2 

Call-ID: 2010@watcherhost.example.com 

CSeq: 8776 NOTIFY 

Event: presence 

Subscription-State: active;expires=3543 

Max-Forwards: 70 

Contact: <sip:server.example.com> 

Content-Type: application/pidf-diff+xml 

Content-Length: 
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<?xml version="1.0" encoding="UTF-8"?> 
<p:pidf-diff xmlns="urn:ietf:params:xml:ns:pidf" 
xmlns:p="urn:ietf:params:xml:ns:pidf-diff" 
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid" 
xml1lns:dm="urn:ietf:params:xml:ns:pidf:data-model" 
entity="sip:resource@example.com" 
version="2"> 


<p:add sel="presence/note" pos="before"><tuple id="ert4773"> 
<status> 

<basic>open</basic> 

</status> 

<contact priority="0.4">mailto:res@example.com</contact> 
<note xml:lang="en">This is a new tuple inserted 

between the last tuple and note element</note> 

</tuple> 


</p:add> 


<p:replace sel="*/tuple[@id=’ r1230d’ ] /status/basic/text ()" 
>open</p:replace> 


<p:remove sel="*/dm:person/r:activities/r:busy"/> 


<p:replace sel="*/tuple[@id=’ cg231ljcr’]/contact/@priority" 
>0.7</p:replace> 


</p:pidf-diff> 
F6 200 OK watcher-> example.com server 


SIP/2.0 200 OK 
Via: SIP/2.0/TCP server.example.com; 
branch=z9hG4bKna998s1 
; received=192.0.2.2 
To: <sip:watcher@example.com>;tag=xfg9 
From: <sip:resource@example.com>;tag=ffd2 
Call-ID: 2010@watcherhost.example.com 
CSeq: 8776 NOTIFY 
Content-Length: 0 
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6. 


Security Considerations 


This specification relies on the presence event package for SIP [3]. 
Partial notifications can reveal information about what has changed 
compared to the previous notification. This can make it easier for 
an eavesdropper to know what kind of changes are happening in the 
presentity's presence information. However, the same information can 
be found if the presence event package is used with baseline PIDF 
[5]. 


A third party can inject a NOTIFY request with partial state that 
will cause the watcher to think it has missed a partial notification 
and to request a new full presence document. This is no worse than 
what we have without this extension since a party that could perform 
such action could also send a NOTIFY with Subscription-State: 
terminated and achieve the same effect without knowing about the 
extension. Partial Notification does not make the situation any 
worse, and the protection mechanisms from the existing system apply 
to preventing this attack against the partial notification mechanism. 


Presence-related security considerations are extensively discussed in 
the presence event package for SIP [3] and all those identified 
security considerations apply to this document as well. Issues 
described in the presence event package for SIP [3], including 
confidentiality, message integrity and authenticity, outbound 
authentication, replay prevention, Denial-of-Service (DoS) attacks 
against thirst parties and DoS attacks against servers all apply here 
without any change. 


It is RECOMMENDED that TLS [7] be used between elements to provide 
hop-by-hop confidentially protection. Furthermore, S/MIME MAY be 
used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. 
This is described in Section 23 of RFC 3261. 
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